\chapter{Introduction}
\label{ch:intro}
\pagenumbering{arabic}

Traditionally, a software system falls into two categories: technical computer-base systems and socio-technical systems \cite{SOMMER-06-SE8}. Technical computer-based systems are systems that include hardware and software components but not procedures and processes. According to the 2001 survey \cite{STANDIS-01}, only 28\% of industry projects are reported as successful, meanwhile 49\% of these were challenged, and 23\% failed altogether. The success of a project refers to its ability to meet stake-holder's expectation, without going over time and budget constraints. These projects failed because they do not recognize the social and organizational complexity of the environment in which the systems are deployed. The consequences of this are unstable requirements, poor systems design and user interfaces that are inefficient and ineffective \cite{SOMMER-09}. Also in \cite{SOMMER-09}, the authors highlight socio-technical systems approaches as a solution.

Socio-technical systems (STS) include one or more technical systems but, crucially, also include knowledge of how the system should be used to achieve some broader objectives. The socio-technical system include in their architecture an operational organizational structure and human actors along with software components. These factors are normally regulated and constrained by internal organizational rules, business processes, external laws and regulations \cite{SOMMER-06-SE8}. This raises new challenges related to analyzing and designing of a STS. In particular, in a STS, human, organizational and software actors rely heavily on each other in order to fulfill their respective objectives. Hence, one important element in the design process is to identify list of actors and dependencies among them which, if respected by all partners, will fulfill all stakeholder goals, a golden key to the success of the STS.

KAOS \cite{DASH-JENN-PARKES-03-IEEE-IS} is a requirement elicitation technique that starts with stakeholder goals and derives functional requirements for a system-to-be and a set of leaf-goal assignments to external actors through a systematic, tool-supported process. However, KAOS does not explore the space of alternative assignments. Consequently, designers have no option to decide what an "optimal" assignment is.

Recently, work in \cite{BRYL-GIOR-MYLOP-09-REJ} has proposed an approach to fill in the gap. The approach is inspired by Tropos \cite{BRES-PERINI-GIOR-GIUN-MYLOP-04-JAAMAS}, an agent-oriented software engineering methodology, which uses the i* modeling framework \cite{YU-96-THESIS} to guide and support the system development process starting from requirements analysis to implementation. This approach constructs a space of assignment configurations by employing an off-the-shelf AI planner and does evaluation on these assignments to help identifying an optimal design. Particularly, the authors address the following problem: given a set of actors, goals, capabilities, and social dependencies, there is a tool generating alternative configurations which are goal-to-actor assignments and dependencies network among actors. The next step is to evaluate alternatives by assessing and comparing them with respect to a number of criteria provided by the designer.

Another important aspect of an STS is its dynamicity. The continuous evolving working environment of an STS makes its structure change dynamicity. This attracts a lot of effort of community to address the problem of dynamic configuration and adaptation of software systems. In \cite{CERNUZZI-ZAMBONELLI-06-AOSE4}, the authors try to adjust the existing agent-oriented methodologies. Work in \cite{BERNON-GLEIZ-PEYRU-PICARD-03-ESAW3} aims at developing an adaptive agent framework (need more detail). Another approach presented in \cite{BRYL-GIOR-06-ITSSA} mixes the idea of AI planning technique with the Tropos methodology to introduce a general architecture that supports dynamic self-reconfiguration at runtime for STS.

We are interested in both supporting the design of STS and self-configurability of an STS. We realize that one most important aspect of our problem is to have a good enough solution space and a quantitative evaluator assessing the assignment solutions so that the designers or the software systems can make decision per se. Bryl et al \cite{BRYL-GIOR-06-ITSSA,BRYL-GIOR-MYLOP-09-REJ} present a framework addressing the problem. However, there is still a gap from the theory to the reality. Inspired by the ideas of Bryl et al, this work aims at constructing an open framework that generates goal-to-actor assignment and dependencies configuration (hereafter configuration or solution) and performs assessment on these solutions based on predefined or user criteria.

\textbf{Contribution} The purpose of our work targets to an open framework that supports both configuration generation and evaluation. Our framework inherits and extends that of Bryl. Specifically, the following highlights the difference between Bryl's and ours:
\begin{itemize}
    \item Early optimization criteria are embedded into the PDDL script in order to prevent the solution space from explosion.
    \item Solution assessment could be extended at runtime. Users or third-party developers can develop and use their own evaluators in just some simple steps.
    \item An event-based simulation performs on each solution to assess the adaptation of solution at runtime with respect to a set of events. Users are able to reuse a set of predefined events or to define their own events.
\end{itemize}

\textbf{Organization} This document is organized as follows:
\begin{itemize}
    \item \emph{Chapter \ref{ch:intro}}: this chapter which give introduction to our work.
    \item \emph{Chapter \ref{ch:background}}: presents preliminary knowledge about goal oriented methodology which is adopted to design socio-technical systems, and the Planning Domain Definition Language (PDDL).
    \item \emph{Chapter \ref{ch:related_work}}: give a glance view about work relevant to self-reconfiguration STS and our framework.
    \item \emph{Chapter \ref{ch:selfreconfigSTS}}: discusses about the approaches of self-reconfiguration STS. It also present the position of the framework in the general basic structure of a centralized self-reconfiguration STS.
    \item \emph{Chapter \ref{ch:Architecture}}: presents the general architecture of the framework.
    \item \emph{Chapter \ref{ch:ODM}}: provides detail information about the organizational descriptor model, which is part of the architecture.
    \item \emph{Chapter \ref{ch:Planning}}: present about the planning problem in both organizational level and instance level.
    \item \emph{Chapter \ref{ch:Assessment}}: discusses about the two kinds of solution assessment, and present some concrete evaluators used in the framework.
    \item \emph{Chapter \ref{ch:Implementation}}: briefly discuss about the prototype of the framework.
    \item \emph{Chapter \ref{ch:experimental}}: presents the experiment of the framework and the prototype.
    \item \emph{Chapter \ref{ch:conc}}: concludes the thesis and raise some future works.
\end{itemize} 